1. Technical Field
This invention relates to the field of advanced intelligent networks and more particularly to a service application architecture for integrated network service providers.
2. Description of the Related Art
The development of the open network application programming interface (API) represents an important departure from traditional methods for opening the architecture of the public switched telephone network (PSTN). One such open network API, the Advanced Intelligent Network (AIN) API and architecture, defines a call model which allows the creation of telecommunications service applications outside of the switch environment. Telecommunications service applications are a"" la carte telecommunications applications which can perform enhanced services for a telecommunications session established among two or more parties. Exemplary services applications can include Call Waiting, Caller ID, Call Forwarding, Voice Activated Dialing, and Meet-me Conferencing.
When AIN first had been introduced, in terms of the service application creation process, the AIN architecture represented an important advance. AIN separated service development from switching, allowing service logic components to be developed more quickly and placed in specialized network elements attached to databases. Switches, in turn, being free from all service logic, could be optimized for speed and efficiency. Still, typical service applications developed to the AIN specification are written in specialized languages by specially trained programmers using specialized service creation environments.
Importantly, future telecommunications networks will be characterized by new and evolving network architectures where packet-switched, circuit-switched, and wireless networks are integrated to offer subscribers an array of innovative multimedia, multiparty applications. Equally important, it is expected that the process by which telecommunications applications are developed will change, and will no longer solely be the domain of the telecommunications network or service application provider. In fact, in order to provide a broad portfolio of novel, compelling applications rapidly, service application providers will increasingly turn to third-party applications developers and software vendors. Thus, application development in the telecommunications domain will become more similar to that in software and information technology in general, with customers reaping the benefits of increased competition, reduced time to market, and the rapid leveraging of new technology as it is developed.
To make this vision a reality, the principles of AIN have been discarded in favor of a new service application component development paradigm. Specifically, it has been recognized that future integrated networks must offer application developers a set of standard, open APIs so that applications written for compatibility with one vendor""s system can execute in the system of another vendor. In consequence, the cost of applications development can be amortized, reducing the final cost to the customer. Java APIs for Integrated Networks (JAIN) fulfills the requirements of the new service application component development paradigm. Presently, JAIN includes standard, open, published Java APIs for next-generation systems consisting of integrated Internet Protocol (IP) or asynchronous transport mode (ATM) networks, PSTN, and wireless networks. The JAIN APIs include interfaces at the protocol level, for different protocols such as Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP), and Transactional Capabilities Application Part (TCAP), as well as protocols residing in the higher layers of the telecommunications protocol stack.
JAIN includes a set of integrated network APIs for the Java platform and an environment to build and integrate JAIN components into services or applications that work across PSTN, packet and wireless networks. The JAIN approach integrates wireline, wireless, and packet-based networks by separating service-based logic from network-based logic. FIG. 1 illustrates a conventional JAIN implementation. As shown in FIG. 1, a conventional JAIN implementation can include a protocol layer 102 which can include interfaces to IP, wireline and wireless signaling protocols. Though only TCAP, JCC and H.323 protocols 110 are shown, the protocols supported by the JAIN specification are not limited to particular protocols and can include, for example, TCAP, ISUP, INAP, MAP, SIP, MGCP, and H.323. Moreover, the JAIN implementation can include an interface to a connectivity management and call control protocol such as JCC.
In addition to the protocol layer 102, the conventional JAIN implementation also can include an application layer 104 for handling secure network access and other external services 120. Also, the conventional JAIN implementation can include a service logic layer 106 which can include a service creation and carrier grade service logic execution environment (SLEE) 108. Service components 112 are the core JAIN components and can execute in the SLEE 108. More particularly, service components 112 can implement telephony and network services and can be constructed according to a standard component model. Instantiations of service component assemblies execute in coordination with the SLEE 108.
In operation, using information regarding the protocol layer 102 which can be incorporated into the SLEE 108, service components 112 can interact with an underlying protocol stack 110 without having specific knowledge of the protocol stack 110. More importantly, the SLEE 108 can relieve the service components 112 of conventional lifecycle responsibilities by providing portable support for transactions, persistence, load balancing, security, and object and connection instance pooling. In this way, the service components 112 can focus on providing telephony and/or network services. Notably, the SLEE 110 can be communicatively linked directly to client components such as external applications 116, protocol stacks 110 and service components 112.
For example, service components 112 executing at the service logic layer 106 in the SLEE 108 can communicate with protocol stacks 110 in the protocol layer through protocol adapters in the SLEE 108. Protocol adapters typically can include class methods, callbacks, encapsulating interfaces, or event handlers. In many cases, an underlying protocol stack 110 can directly communicate with the SLEE 108 through an event table 114 in the SLEE 108 which can be configured to specifically handle events which are particular to the underlying protocol stack 110. In consequence, the SLEE 108 can recognize those particular events, and upon receipt of such an event from the underlying protocol stack 110, the SLEE 108 can pass the event to a subscribing service component 112. Also, service components 112 can be individually programmed to interact with specific external services 120, such as relational databases, directory services, etc.
Despite the apparent advantages of the JAIN specification, however, conventional implementations of the JAIN specification include some drawbacks. particularly in their application to real-time telephony. First, the SLEE of conventional JAIN implementations incorporate an Enterprise Javabean(copyright) (EJB) approach which includes unnecessary system housekeeping chores, for example lifecycle responsibilities. Lifecycle responsibilities, however, are not as critical in the real-time telephony domain as they are in other communications domains. Thus, the use of EJBs can introduce too many latencies to satisfy the demands of real time operations. More importantly, in order to relieve service components of the complexities of the protocol stacks, conventional SLEEs require specific knowledge of the underlying protocol layer.
For instance, to communicate with the protocol stacks in the protocol layer, the SLEE requires specific knowledge of the underlying protocol stacks as will be apparent from corresponding event tables which can be used to facilitate communications between the SLEE and an underlying protocol stack. Including specific client component information in the SLEE, however, can add unnecessary complexity to the SLEE. From a life-cycle maintenance perspective this can be problematic. Also, including client component information in the SLEE unnecessarily directly binds the SLEE to particular client components. Finally, directly binding the SLEE to particular client components can require the positioning of the application layer, protocol layer and the service logic layer in close computing proximity to one another. Hence, what is needed is a more flexible service application architecture for integrated network service providers.
The present invention is a flexible service application architecture for integrated network service providers. The present invention solves the deficiencies of the prior art by providing more direct processing of events by the service components and by reducing protocol stack specific code contained in the service logic execution environment (SLEE). Additionally, the present invention can solve the deficiencies of the prior art by removing specific client component information from the SLEE and substituting therefor a connector/wrapper communications interface. As a result, the SLEE can generically transmit and receive communications through the connector/wrapper interface regardless of the implementation details of the underlying client components. Hence, in accordance with the inventive arrangements, the complexity of the SLEE can be reduced. Moreover, a SLEE configured in accordance with the inventive arrangements need not be directly bound to particular client components.
Finally, the architecture of the present invention can include generic service components which can be configured to communicate with specific external services while providing a generic interface to other service components executing in the SLEE. In this way, service components executing in the SLEE, for example telephony service components, can generically request external services such as database operations from the generic service component. Responsive to receiving a generic request for an external service, the generic service component can invoke one or more functions specific to a corresponding specific external service in order to provide the requested external service to the requesting telephony service component. Consequently, telephony service components need not incorporate specific code directed to a specific external service. Rather, only the generic service component need incorporate specific code directed to the specific external service. Thus, the complexity of the telephony service components can be reduced.
An application execution environment for an intelligent network having a protocol layer, service logic layer and an application layer, which has been configured in accordance with the inventive arrangements can include a SLEE in the service logic layer. Notably, the SLEE can be a JAIN-compliant SLEE. The SLEE can include an event routing bus for routing events between service components in the service logic layer and client components in the protocol layer and application layer. Importantly, the client components can include a protocol stack. Furthermore, the client component can include call-control components, signaling protocol components, connectivity management protocol components, and secure network access protocol components.
The application execution environment also can include at least one client component in the protocol layer, wherein the at least one client component is communicatively linked to the SLEE through a connector/wrapper interface. Finally, the application execution environment can include at least one telephony service component executing in the SLEE, wherein the telephony component can be configured to communicate with client components in the protocol layer and other service components in the service logic layer through the event routing bus in the SLEE. The application execution environment can also include at least one generic service component executing in the SLEE. The generic service component can be configured to communicate with other service components in the SLEE. The generic service component also can be configured to communicated with specific external services in the application layer.
The connector/wrapper interface can include a client component wrapper, the client component wrapper providing an abstracted interface to a client component in the protocol layer; and, a connector associated with the SLEE, the connector corresponding to the client component wrapper, wherein the connector is configured to communicate with the client component through the abstracted interface provided by the client component wrapper. Additionally, the application execution environment can include a SLEE descriptor, the SLEE descriptor specifying at least one client component with which the SLEE can be configured to communicate through a connector/wrapper interface. Similarly, the application execution environment can include at least one client component descriptor, each client component descriptor corresponding to a specific client component in the protocol layer, the at least one client component descriptor specifying particular events for which the specific client component can be notified by the event routing bus in the SLEE.
A telephony services provisioning method in accordance with the inventive arrangements can include the following steps performed partially in an event routin bus in a SLEE, and partially in a service component. First, in an event routing bus in a service logic execution environment (SLEE), protocol layer events can be received from client components through a connector/interface wrapper. Also, service logic layer events can be received from service components executing in the SLEE. Finally, the particular protocol layer events and the service logic layer events can be forwarded to service components and client components registered to receive the particular protocol layer and service logic layer events.
Second, in at least one of the service components executing in the SLEE, at least one service logic layer event can be posted to the event routing bus, wherein the event routing bus can forward the posted service logic layer event to another service component registered to receive the posted service logic layer event. Notably, in at least one of the service components, a communications link can be established with a specific external service; a service logic layer event can be received from another service component, the received event requesting an external service; and, responsive to receiving the service logic layer event from another service component, the requested external service can be provided through at least one specific call to a function provided by the linked specific external service.